IB/FB - Lock zaznamu - casy
Otázka od: Ing. Jiri SOKOL
12. 12. 2002 8:24
Ahoj.
Chci si jenom overit nektere udaje, ktere jsem zjistil.
Na konferenci jsem se docetl, ze IB/FB "nepouziva" zamykani zaznamu - aspon z
dlouhodobeho hlediska
a ze se to muze "obejit" trikem update ... set id=id where id=1 (napr.)
1) Co me zajima je ..., kdyz udelam takovyto zamek jak dlouho bude zamknuto?
Zkousel jsem to cca po hodine a porad, i kdyz jsem na pocitac ani nesahl, byl
zaznam uzamcen. Tohle
by mohlo byt nebezpeci zamku.
Kdyz jsem simuloval pad aplikace, tak se lock uvolnil cca kolem 3 min.
2) Jde nejak ovlnit tyto casove hodnoty?
Premyslel jsem o tom, nastavit nejaky timer, ktery se bude obnovovat pri kazdem
stisku klavesy a
pohybu mysi a dat nejaky "uvolnovaci" interval a kdyz uzivatel dlouho nic s
pociatcem delat nebude,
zamek uvolnit
3) co si o tomhle napadu myslite? resite to jinak?
Diky za napady
Jirka
Ing. Jiri Sokol, js-delphi@seznam.cz, +420251431187
D6ProfSP2,WinNT
amatersky programator
______________________________________________________________________
Reklama:
MP3 autorádio SONY CDX-MP30 za 8 990,-!/10 hodin hudby na jednom CD/odním.
čelní panel/4x50W/D-bass/CD-R,RW play
http://ad2.seznam.cz/redir.cgi?instance=38953%26url=http://www.sony-mobile.cz/
Odpovedá: Roman Macura
12. 12. 2002 8:17
Zamek nastav v ramci transakce a kdyz jej chces uvolnit, ukonci transakci.
----- Original Message -----
From: "Ing. Jiri SOKOL" <JS-delphi@seznam.cz>
To: "dotaz-delp" <delphi-l@clexpert.cz>
Sent: Thursday, December 12, 2002 8:04 AM
Subject: IB/FB - Lock zaznamu - casy
Ahoj.
Chci si jenom overit nektere udaje, ktere jsem zjistil.
Na konferenci jsem se docetl, ze IB/FB "nepouziva" zamykani zaznamu - aspon
z dlouhodobeho hlediska
a ze se to muze "obejit" trikem update ... set id=id where id=1 (napr.)
1) Co me zajima je ..., kdyz udelam takovyto zamek jak dlouho bude zamknuto?
Zkousel jsem to cca po hodine a porad, i kdyz jsem na pocitac ani nesahl,
byl zaznam uzamcen. Tohle
by mohlo byt nebezpeci zamku.
Kdyz jsem simuloval pad aplikace, tak se lock uvolnil cca kolem 3 min.
2) Jde nejak ovlnit tyto casove hodnoty?
Premyslel jsem o tom, nastavit nejaky timer, ktery se bude obnovovat pri
kazdem stisku klavesy a
pohybu mysi a dat nejaky "uvolnovaci" interval a kdyz uzivatel dlouho nic s
pociatcem delat nebude,
zamek uvolnit
3) co si o tomhle napadu myslite? resite to jinak?
Diky za napady
Jirka
Ing. Jiri Sokol, js-delphi@seznam.cz, +420251431187
D6ProfSP2,WinNT
amatersky programator
______________________________________________________________________
Reklama:
MP3 autorádio SONY CDX-MP30 za 8 990,-!/10 hodin hudby na jednom CD/odním.
čelní panel/4x50W/D-bass/CD-R,RW play
http://ad2.seznam.cz/redir.cgi?instance=38953%26url=http://www.sony-mobile.c
z/
Odpovedá: Pavel Cisar
12. 12. 2002 11:23
Haj hou!
On 12 Dec 2002 at 8:04, Ing. Jiri SOKOL wrote:
> Chci si jenom overit nektere udaje, ktere jsem zjistil.
> Na konferenci jsem se docetl, ze IB/FB "nepouziva" zamykani zaznamu - aspon z
dlouhodobeho hlediska
> a ze se to muze "obejit" trikem update ... set id=id where id=1 (napr.)
Tento pristup ma jeden zavazny nedostatek. Pri "falesnem" update jsou
provadeny vsechny kontroly a triggery navesene na danou tabulku. To muze
byt u nekterych aplikaci zavazny problem.
> 1) Co me zajima je ..., kdyz udelam takovyto zamek jak dlouho bude zamknuto?
Do ukonceni transakce v ramci ktere byla zmena provedena.
> Zkousel jsem to cca po hodine a porad, i kdyz jsem na pocitac ani nesahl, byl
zaznam uzamcen. Tohle
> by mohlo byt nebezpeci zamku.
Konecne jsi na to kapnul Problem pesimistickeho zamykani narusta
primou umerou s poctem soucasne pracujicich uzivatelu krat prumernou
delkou transakce krat mnozstvim provedenych zmen v ramci jedine
transakce. U systemu s vice jak jednim uzivatelem je z hlediska
skalovatelnosti reseni zcela nevhodne. Az na velmi vyjmecne pripady se
bez pesimistickeho zamykani lze vzdy obejit.
> Kdyz jsem simuloval pad aplikace, tak se lock uvolnil cca kolem 3 min.
Protoze po urcite dobe si server uvedomil pad klienta a ukoncil spojeni a
transakci.
> 2) Jde nejak ovlnit tyto casove hodnoty?
Ukoncenim transakce.
> Premyslel jsem o tom, nastavit nejaky timer, ktery se bude obnovovat pri
kazdem stisku klavesy a
> pohybu mysi a dat nejaky "uvolnovaci" interval a kdyz uzivatel dlouho nic s
pociatcem delat nebude,
> zamek uvolnit
>
> 3) co si o tomhle napadu myslite? resite to jinak?
Nic moc, lepsi je nepouzivat pesimisticke zamykani.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Roman Macura
12. 12. 2002 11:14
A u systemu s jednim uzivatelem nepotrebujete zamykani , ze
Zajimalo by me, jak se optimistickym pristupem elegantne vyresi to,
ze vice uzivatelu najednou upravuje jeden zaznam treba nekolik minut
(napr. vyplneni nejakeho delsiho formulare a jeho potvrzeni az nakonec)
a v ramci techto uprav zmeni vsichni jednu z polozek. Pokud se nepletu,
pak vsem krome prvniho / posledniho (podle nastaveni modu transakce)
se ani nahodou nepodari tuto polozku ulozit a v zavislosti na jeji
dulezitosti
mohou prijit o vsechna sva pracne zadavana data
(pokud je aplikace neuchovava jinak nez pomoci otevreneho cursoru).
Jake je elegantnejsi reseni, nez dat vsem ostatnim pri pokusu o editaci
takoveho
zaznamu na vedomi, ze ted nemuzou, protoze jej edituje nekdo jiny
(pesimisticky pristup)?
----- Original Message -----
From: "Pavel Cisar" <pcisar@users.sourceforge.net>
To: <delphi-l@clexpert.cz>
Sent: Thursday, December 12, 2002 11:02 AM
Subject: Re: IB/FB - Lock zaznamu - casy
> Haj hou!
>
> On 12 Dec 2002 at 8:04, Ing. Jiri SOKOL wrote:
>
> > Chci si jenom overit nektere udaje, ktere jsem zjistil.
> > Na konferenci jsem se docetl, ze IB/FB "nepouziva" zamykani zaznamu -
aspon z dlouhodobeho hlediska
> > a ze se to muze "obejit" trikem update ... set id=id where id=1 (napr.)
>
> Tento pristup ma jeden zavazny nedostatek. Pri "falesnem" update jsou
> provadeny vsechny kontroly a triggery navesene na danou tabulku. To muze
> byt u nekterych aplikaci zavazny problem.
>
> > 1) Co me zajima je ..., kdyz udelam takovyto zamek jak dlouho bude
zamknuto?
>
> Do ukonceni transakce v ramci ktere byla zmena provedena.
>
> > Zkousel jsem to cca po hodine a porad, i kdyz jsem na pocitac ani
nesahl, byl zaznam uzamcen. Tohle
> > by mohlo byt nebezpeci zamku.
>
> Konecne jsi na to kapnul Problem pesimistickeho zamykani narusta
> primou umerou s poctem soucasne pracujicich uzivatelu krat prumernou
> delkou transakce krat mnozstvim provedenych zmen v ramci jedine
> transakce. U systemu s vice jak jednim uzivatelem je z hlediska
> skalovatelnosti reseni zcela nevhodne. Az na velmi vyjmecne pripady se
> bez pesimistickeho zamykani lze vzdy obejit.
>
> > Kdyz jsem simuloval pad aplikace, tak se lock uvolnil cca kolem 3 min.
>
> Protoze po urcite dobe si server uvedomil pad klienta a ukoncil spojeni a
> transakci.
>
> > 2) Jde nejak ovlnit tyto casove hodnoty?
>
> Ukoncenim transakce.
>
> > Premyslel jsem o tom, nastavit nejaky timer, ktery se bude obnovovat pri
kazdem stisku klavesy a
> > pohybu mysi a dat nejaky "uvolnovaci" interval a kdyz uzivatel dlouho
nic s pociatcem delat nebude,
> > zamek uvolnit
> >
> > 3) co si o tomhle napadu myslite? resite to jinak?
>
> Nic moc, lepsi je nepouzivat pesimisticke zamykani.
>
> S pozdravem
> Pavel Cisar
> Mobil: 724 281429
> http://www.ibphoenix.cz
> Vse co potrebujete pro Firebird a InterBase
>
>
Odpovedá: Lstiburek Pavel
12. 12. 2002 15:33
> From: Roman Macura [mailto:delphi@atlascon.cz]
> A u systemu s jednim uzivatelem nepotrebujete zamykani , ze
>
> Zajimalo by me, jak se optimistickym pristupem elegantne vyresi to,
> ze vice uzivatelu najednou upravuje jeden zaznam treba nekolik minut
> (napr. vyplneni nejakeho delsiho formulare a jeho potvrzeni
> az nakonec)
> a v ramci techto uprav zmeni vsichni jednu z polozek. Pokud
> se nepletu,
> pak vsem krome prvniho / posledniho (podle nastaveni modu transakce)
> se ani nahodou nepodari tuto polozku ulozit a v zavislosti na jeji
> dulezitosti
> mohou prijit o vsechna sva pracne zadavana data
> (pokud je aplikace neuchovava jinak nez pomoci otevreneho cursoru).
> Jake je elegantnejsi reseni, nez dat vsem ostatnim pri pokusu
> o editaci
> takoveho
> zaznamu na vedomi, ze ted nemuzou, protoze jej edituje nekdo jiny
> (pesimisticky pristup)?
Ahoj,
rozhodnuti o zamykani pesimistickem a optimistickem musi vychazet z
konkretni
aplikace:
1. jak casto se zaznamy opravuji (podil vkladani/zuseni/editace)?
2. jaka je pravdepodobnost, ze bude opravan zaznam vice nez jednim
uzivatelem ?
3. kolik bude stat nutnost provest zmeny znovu ?
4. kolik bude stat zvyseni vykonu db engine ?
i v pripade vyhodnosti pesimistickeho zamykani se to resi radeji jinak
(optimisticky):
napr.:
1. provedu pokus ulozit udaje,
2. pokud se to neprovede neb to nekdo zmenil, zjistim co se zmenilo,
(jedny data mam v editacnim cursoru dalsi si natahnu do noveho)
3a. rozhodnu co dal (nejaky algoritmus)
3b. uzivatel rozhodne co dal (po zobrazeni rozdílu si vybere kde nove
hodnoty a kde stare)
4. pokracuj bodem 1.
Rozhodnout se da pouze pri znalosti zpusobu prace s aplikaci !
Dovoluji si podoknout (jiste to neni tvuj pripad, pouze rada zacatecnikum),
ze neni v tomto pripade mozno pouzit komponenty prehled-detail a opravovat
dle
prehledu. Ten obsahuje stara data z okamziku dataset.open!
Pred opravou je nutno zkusit zda dany zaznam vubec v DB jeste je,
zahajit transakci s dostatecnym stupnem isolace, znovu jej nacist
(je dobre dle neceho poznat, zda mi to v te chvilicce nekdo nezmenil pod
rukama)
a potom teprve zacit neco delat. Vyzkousena kombinace:
prehledy dirtyread - cte vsechno, libovolny srot, ale na nic neceka,
detail nejaka vysi isolation level s omezenym timeout - kdyz to padne tak to
nekdo drzi
=> Nejdele tedy trva zjistit, ze to nemohu opravovat, cely timeout.
Poznamka (pouze na okraj):
pokud neni aplikaci telefonni seznam nebude se zamykat zaznam v jedne
tabulce,
ale v nekolika (mozna i nekolik zaznamu) mozna i v nekolika desitkach
tabulek, uhlidat to rucne
muze byt docela problem.
Pavel
Odpovedá: Roman Macura
12. 12. 2002 15:43
Samozrejme mas pravdu, mne jenom opet po asi pul roce (kdy o tom byla
posledni diskuse) nastvalo,
ze nekdo vklidu "odsoudi" nejaky princip implementace, ktery je za urcitych
okolnosti vhodnejsi nez aktualne pouzivany a doporucovany princip,
ale hlavne vyzadovany (!!!) velkym mnozstvim nasich klientu.
A taky mne opravdu zajimalo, jestli nekdo vymyslel jak pri pouziti
optimistickeho zamykani
osetrit takoveto stavy jinak nez ex-post. Ale asi to uz nikdo nevymysli a
uzivatele, kterym
se to stane se budou muset smirit s resenim, ktere popisujeme oba ve svych
prispevcich.
----- Original Message -----
From: "Lstiburek Pavel" <Lstiburek@ceb.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, December 12, 2002 3:12 PM
Subject: RE: IB/FB - Lock zaznamu - casy
> From: Roman Macura [mailto:delphi@atlascon.cz]
> A u systemu s jednim uzivatelem nepotrebujete zamykani , ze
>
> Zajimalo by me, jak se optimistickym pristupem elegantne vyresi to,
> ze vice uzivatelu najednou upravuje jeden zaznam treba nekolik minut
> (napr. vyplneni nejakeho delsiho formulare a jeho potvrzeni
> az nakonec)
> a v ramci techto uprav zmeni vsichni jednu z polozek. Pokud
> se nepletu,
> pak vsem krome prvniho / posledniho (podle nastaveni modu transakce)
> se ani nahodou nepodari tuto polozku ulozit a v zavislosti na jeji
> dulezitosti
> mohou prijit o vsechna sva pracne zadavana data
> (pokud je aplikace neuchovava jinak nez pomoci otevreneho cursoru).
> Jake je elegantnejsi reseni, nez dat vsem ostatnim pri pokusu
> o editaci
> takoveho
> zaznamu na vedomi, ze ted nemuzou, protoze jej edituje nekdo jiny
> (pesimisticky pristup)?
Ahoj,
rozhodnuti o zamykani pesimistickem a optimistickem musi vychazet z
konkretni
aplikace:
1. jak casto se zaznamy opravuji (podil vkladani/zuseni/editace)?
2. jaka je pravdepodobnost, ze bude opravan zaznam vice nez jednim
uzivatelem ?
3. kolik bude stat nutnost provest zmeny znovu ?
4. kolik bude stat zvyseni vykonu db engine ?
i v pripade vyhodnosti pesimistickeho zamykani se to resi radeji jinak
(optimisticky):
napr.:
1. provedu pokus ulozit udaje,
2. pokud se to neprovede neb to nekdo zmenil, zjistim co se zmenilo,
(jedny data mam v editacnim cursoru dalsi si natahnu do noveho)
3a. rozhodnu co dal (nejaky algoritmus)
3b. uzivatel rozhodne co dal (po zobrazeni rozdílu si vybere kde nove
hodnoty a kde stare)
4. pokracuj bodem 1.
Rozhodnout se da pouze pri znalosti zpusobu prace s aplikaci !
Dovoluji si podoknout (jiste to neni tvuj pripad, pouze rada zacatecnikum),
ze neni v tomto pripade mozno pouzit komponenty prehled-detail a opravovat
dle
prehledu. Ten obsahuje stara data z okamziku dataset.open!
Pred opravou je nutno zkusit zda dany zaznam vubec v DB jeste je,
zahajit transakci s dostatecnym stupnem isolace, znovu jej nacist
(je dobre dle neceho poznat, zda mi to v te chvilicce nekdo nezmenil pod
rukama)
a potom teprve zacit neco delat. Vyzkousena kombinace:
prehledy dirtyread - cte vsechno, libovolny srot, ale na nic neceka,
detail nejaka vysi isolation level s omezenym timeout - kdyz to padne tak to
nekdo drzi
=> Nejdele tedy trva zjistit, ze to nemohu opravovat, cely timeout.
Poznamka (pouze na okraj):
pokud neni aplikaci telefonni seznam nebude se zamykat zaznam v jedne
tabulce,
ale v nekolika (mozna i nekolik zaznamu) mozna i v nekolika desitkach
tabulek, uhlidat to rucne
muze byt docela problem.
Pavel
Odpovedá: Martin Schayna
12. 12. 2002 16:06
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> A taky mne opravdu zajimalo, jestli nekdo vymyslel jak pri pouziti
> optimistickeho zamykani osetrit takoveto stavy jinak nez ex-post.
> Ale asi to uz nikdo nevymysli a uzivatele, kterym se to stane se
> budou muset smirit s resenim, ktere popisujeme oba ve svych
> prispevcich.
A co takhle: predpokladejme ze oprava jednoho zaznamu = zmeny
ve vice tabulkach v ramci jedne transakce (napr. oprava dokladu
s jeho radky, odepsani ze skladu apod.). Chceme pouzivat
optimisticke zamykani a kratkodobe transakce pouze behem ukladani,
proto vyloucime zamky typu UPDATE beze zmen nebo SELECT
FOR UPDATE.
Paralelne k IB nam na serveru pobezi jeste jeden jednoduchy TCP
server, ktery bude realizovat zamky. Klientska aplikace se pred
rozeditovanim dokladu pokusi "zamknout" pomoci nejake vhodne
identifikace vyplyvajici z logiky aplikace (napr. retezec jednoznacne
identifikujici doklad) a pokud ji to neprojde, oznami se uzivateli
ze v tom nekdo stoji. Takovy TCP server nebude zatezovat
databazi pesimistickymi zamky a jeho rezie bude minimalni.
Nevyhodou je ze klientska aplikace musi vzdy pred opravou
zpusobit to zamceni, ale to se da odstranit vhodnym objektovym
navrhem klienta. Protoze je to relativne samostatne, mohlo by
byt toto zamykani pro aplikaci i volitelne.
Co vy na to?
Martin Schayna
Odpovedá: Lstiburek Pavel
12. 12. 2002 16:34
Ahoj,
pokud jses schopen zajistit, ze k datum bude pristupovat pouze tvoje
aplikace,
tedy zadne via ODBC exely a jina udelatka, tak je mozne mechanizmus zamku
vybudovat na zaklade znalosti prace s daty. Toto reseni neni obecne, ale
musi
opakovane vymyslet pro kazdou aplikaci.
Nejjednodusi reseni (pokud se aplikace spousti na jedne stanici max. jednou)
je vytvorit si tabulku pro kazdou pracovni stanici a tu naplnit zaznamy
"zamcenych"
klicu. Pokud znas hierarchii udate zaznamu v tabulkach, tak staci "zamykat"
vzdy pouze,
"vrcholy" (nejvyssi shodne). Idealni je napsat si SP, ktere resi
"zadost o
zamek" a
SP, ktere resi zapis udaju a zaroven (v transakci) "odemknou prislusny
zamek".
Pokud server podporuje joby staci spustit kazdych "n" minut proceduru,
ktera odemkne vsechny zamky jejich stanice jiz nejsou prihlaseny.
..... atd.
Variaci na toto tema se da vymyslet dost, ale zadna neni OBECNA, vzdy
vyzaduje dodrzovani
nejakeho nepsaneho PRAVIDLA, proto je servery neimplementuji.
Nejobecnejsim resenim je vlozit mezi front-end a DB dalsi vrstvu = aplikacni
server,
ten bude tato pravidla kontrolovat a pristup k datum (DB) bude mozny pouze
prostrednictvim tohoto serveru tj. vzdy "dle pravidel".
Implementace pomoci Delphi je (relativne) snadna (nikoliv vsak levna).
Pavel
> From: Roman Macura [mailto:delphi@atlascon.cz]
> Samozrejme mas pravdu, mne jenom opet po asi pul roce (kdy o tom byla
> posledni diskuse) nastvalo,
> ze nekdo vklidu "odsoudi" nejaky princip implementace, ktery
> je za urcitych
> okolnosti vhodnejsi nez aktualne pouzivany a doporucovany princip,
> ale hlavne vyzadovany (!!!) velkym mnozstvim nasich klientu.
>
> A taky mne opravdu zajimalo, jestli nekdo vymyslel jak pri pouziti
> optimistickeho zamykani
> osetrit takoveto stavy jinak nez ex-post. Ale asi to uz nikdo
> nevymysli a
> uzivatele, kterym
> se to stane se budou muset smirit s resenim, ktere popisujeme
> oba ve svych
> prispevcich.
Odpovedá: Pavel Cisar
12. 12. 2002 18:33
Haj hou!
On 12 Dec 2002 at 11:10, Roman Macura wrote:
> Zajimalo by me, jak se optimistickym pristupem elegantne vyresi to,
> ze vice uzivatelu najednou upravuje jeden zaznam treba nekolik minut
> (napr. vyplneni nejakeho delsiho formulare a jeho potvrzeni az nakonec)
> a v ramci techto uprav zmeni vsichni jednu z polozek.
Pro vetsinu aplikaci velmi nepravdepodobne. Drtiva vetsina vsech
databazovych aplikaci ma nasledujici strukturu prace s daty (85% insert,
10% update, 5% delete). Konflikt muze vzniknout pouze u operaci update a
delete, tedy 15% vsech operaci ktera meni obsah databaze.
Pravdepodobnost, ze dva uzivatele v jeden okamzik meni to same, je bezne
velmi nizka, a da se dale snizit i vhodnou organizaci dat i stylu prace.
V tech vzacnych pripadech kdy je pravdepodobnost vyssi se bud zvazi zda
lze praci koncipovat jinak a snizit pravdepodobnost, nebo se realizuje
prislusna synchronizace, ale na urovni aplikace. Uzamykat data na urovni
databaze je vetsinou blbost, protoze menena data byvaji dost komplexni
(kdyby nebyla, tak je proste pri kolizi jeden z uzivatelu zada znova a
hotovo). Proto se vyplati zamykani na logicke urovni, napr. vlastnim
manazerem zamku kde se "uzamkne" identifikator bloku dat.
Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak je
neco seredne spatne s navrhem databaze i aplikace.
Pesimisticke zamykani je prosty system na bazi vyhradniho rezervovani
zdroju, a jako takovy je nejuzsim moznym hrdlem soubezneho zpracovani.
Zdroje je treba vhodne _ridit_, nikoliv rezervovat. Nic proti serializaci
pokud je nezbytna (a to je malo kdy), ale vzdy je treba s ni zachazet s
nejvyssi opatrnosti a stridmosti. Postavit na serializaci viceuzivatelsky
system je naprosta pitomost, ktera se vzdy seredne podepise na
skalovatelnosti a celkovem vykonu systemu.
Hledejte predevsim *spravna* reseni, nikoliv prednostne ta
*nejjednodussi* (i kdyz idealem jsou nejjednodussi spravna reseni
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Jan Sebelík
13. 12. 2002 14:14
> Odesílatel: Pavel Cisar <pcisar@users.sourceforge.net>
> > 3) co si o tomhle napadu myslite? resite to jinak?
> Nic moc, lepsi je nepouzivat pesimisticke zamykani.
> Hledejte predevsim *spravna* reseni, nikoliv prednostne ta
> *nejjednodussi* (i kdyz idealem jsou nejjednodussi spravna reseni
Souhlas, souhlas, souhlas.
Pokud pracujeme s BDE, IBX a pod., tedy jsme "v primem kontaktu" s databazi,
pak to (alespon nekoho) casto svadi k nejakemu tomu zamykani.
Pokud se rozhodneme pro TClientDataSet, zejmena pak ve vicevrstve aplikaci, pak
se negativni dusledky ruznych pokusu o zamykani umocnuji na n-tou, pokud to
vubec neni nesmysl. Je to zcela jiny styl prace s daty.
Pritom prave TClientDataset (ve spolupraci s TDataSetProvider) resi konflikty
nad jednim zaznamem jednoduse, elegantne a jsem presvedcen, ze i spravne.
Otevru TClientDataset, nacucnu data, zdrojovy dataset pod TDataSetProvider se
zavre, transakce se ukonci (mela by se ukoncit). Pak si s daty mohu delat co
chci, treba si je odvezt na vikend (SaveToFile, LoadFromFile) a v pondeli je
upravena zase vratit do databaze (LoadFromFile, ApplyUpdates).
ApplyUpdates probehne v jedne kratke transakci. Kdyz ne, tak mu pomuzu - treba
v IBX se po ApplyUpdates transakce sama neukonci.
Pokud doslo ke konfliktu, dostanu (OnReconcileError) zpravu: nacetl jsi A,
zmenil jsi to na B, na server ale mezitim nekdo zapsal C. Co s tim chces delat?
To pro kazdou polozku v tabulce zvlast. A ja odpovim Skip (kdyz nevim), Refresh
(kdyz ma pravdu C), Merge (kdyz mam pravdu ja), pripadne Correct (kdyz mame
pravdu oba, kazdy ale na jine polozce zaznamu).
Podle meho soudu je to docela blizke tem pristupum, ktere zcela odmitaji
DBAware komponenty a resi problem (nacitani dat, editace, zapis, reseni
konfliktu) vlastnimi prostredky (Z.Hlinka a spol.)
Snadne, elegantni.
Viz kurz Vicevrstve aplikace.
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================
Odpovedá: Radek KALA
13. 12. 2002 12:41
To je docela dobrej napad. A logiku toho zamykani at se na to
nezapomene by slo dodelat do IBDataSet a uz se nemusim o nic
starat.
>
> A co takhle: predpokladejme ze oprava jednoho zaznamu = zmeny
> ve vice tabulkach v ramci jedne transakce (napr. oprava dokladu
> s jeho radky, odepsani ze skladu apod.). Chceme pouzivat
> optimisticke zamykani a kratkodobe transakce pouze behem ukladani,
> proto vyloucime zamky typu UPDATE beze zmen nebo SELECT FOR UPDATE.
>
> Paralelne k IB nam na serveru pobezi jeste jeden jednoduchy TCP
> server, ktery bude realizovat zamky. Klientska aplikace se pred
> rozeditovanim dokladu pokusi "zamknout" pomoci nejake vhodne
> identifikace vyplyvajici z logiky aplikace (napr. retezec jednoznacne
> identifikujici doklad) a pokud ji to neprojde, oznami se uzivateli ze
> v tom nekdo stoji. Takovy TCP server nebude zatezovat databazi
> pesimistickymi zamky a jeho rezie bude minimalni. Nevyhodou je ze
> klientska aplikace musi vzdy pred opravou zpusobit to zamceni, ale to
> se da odstranit vhodnym objektovym navrhem klienta. Protoze je to
> relativne samostatne, mohlo by byt toto zamykani pro aplikaci i
> volitelne.
>
> Co vy na to?
>
> Martin Schayna
>
S pozdravem Radek KALA
BetaControl, s.r.o.
Cerneho 58/60, 635 00
tlf. : + 420 5 4622 3491
fax : + 420 5 4622 3470
GSM : + 420 603 85 75 15
Odpovedá: Petr Fejfar
13. 12. 2002 15:57
From: "Martin Schayna" <mschayna@aktis.cz>
> Paralelne k IB nam na serveru pobezi jeste jeden jednoduchy
> TCP server, ktery bude realizovat zamky. Klientska aplikace se pred
> rozeditovanim dokladu pokusi "zamknout" pomoci nejake vhodne
> identifikace vyplyvajici z logiky aplikace (napr. retezec jednoznacne
> identifikujici doklad) a pokud ji to neprojde, oznami se uzivateli
> ze v tom nekdo stoji. Takovy TCP server nebude zatezovat
Nejak mi unika, k cemu potrebujes ten samostatny TCP server.
Takovy zamek muzes prece implementovat pouze prostredky
SQL serveru:
LOCK - v samostatne serializable transakci udelas
insert unique identifikatoru (dokladu) do tabulky zamku
(kdyz dostanes key violation - uz je to zamknuto)
RELEASE - v samostatne serializable transakci udelas
delete toho identifikatoru (dokladu)
a osetris to jako jakykoli jiny sdileny prostredek, tedy
LOCK;
try
// Transakce editujici zamknuty zaznam
finally
RELEASE;
end;
Samozrejme to muzes cele zapouzdrit do nejake tridy napr. TSQLDocumentLock s
metodami Lock() a Release().
Bye, pf
Odpovedá: Karel Rys
13. 12. 2002 16:24
Pavel Cisar dne 12 Dec 2002 v 18:15:
> Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak
> je neco seredne spatne s navrhem databaze i aplikace.
S tim bych tak docela nesouhlasil.
Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne. Pri zapsani
radku do prodejniho
dokladu je nutne snizit fyzickou zasobu. Zde je proste treba pripadny konflikt
nejak osetrit,
podle meho nazoru nejde predejit moznosti, ze ke konfliktu dojde... Je ale
pravda, ze pokud je
rychla sit, transakce potrva kratkou dobu a ta pravdepodobnost neni az *tak
velka*
Karel Rys
Odpovedá: Martin Schayna
13. 12. 2002 16:37
----- Original Message -----
From: "Petr Fejfar" <development@callnet.cz>
> From: "Martin Schayna" <mschayna@aktis.cz>
> > Paralelne k IB nam na serveru pobezi jeste jeden jednoduchy
> > TCP server, ktery bude realizovat zamky. Klientska aplikace se pred
>
> Nejak mi unika, k cemu potrebujes ten samostatny TCP server.
>
> Takovy zamek muzes prece implementovat pouze prostredky
> SQL serveru:
>
> LOCK;
> try
> // Transakce editujici zamknuty zaznam
> finally
> RELEASE;
> end;
>
Ja chci odstranit dlouhotrvajici transakce, neco jako LOCK by se
dal zavolat vzdy pred zahajenim editace, v ten okamzik se stahnou
na klienta data ktera zacne opravovat a muze je opravovat treba
hodinu (transakce je uzavrena, IB server je spokojeny) pri ulozeni
se zahaji transakce, ulozi se data a provede se neco jako RELEASE.
Zamek muze mit nejaky timeout, v tom pripade se musi rozeznat
ze zaznamy byly mezitim zmeneny jinym uzivatelem, my pouzivame
malinky trigger u kazde tabulky ktery pri zmene meni cislo verze
zaznamu.
BTW, to co popisujes tj. metody LOCK a RELEASE jsou metody
ceho? Mluvime o stejnem databazovem stroji? Pokud se jedna o
SQL Server, musi byt LOCK a RELEASE volany v ramci transakce?
Pokud ano, neresi to nas problem.
Martin Schayna
Odpovedá: Martin Schayna
13. 12. 2002 16:46
----- Original Message -----
From: "Karel Rys" <delphi@zas-me.cz>
> Pavel Cisar dne 12 Dec 2002 v 18:15:
>
> > Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak
> > je neco seredne spatne s navrhem databaze i aplikace.
>
> S tim bych tak docela nesouhlasil.
>
> Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne. Pri zapsani
radku do prodejniho
> dokladu je nutne snizit fyzickou zasobu. Zde je proste treba pripadny
konflikt nejak osetrit,
> podle meho nazoru nejde predejit moznosti, ze ke konfliktu dojde... Je ale
pravda, ze pokud je
> rychla sit, transakce potrva kratkou dobu a ta pravdepodobnost neni az *tak
velka*
Z vlastni zkusenosti vim ze toto je *velka* pravdepodobnost.
Priklad reseni: na tabulce se zasobou si udelej polozku s verzi (staci Integer)
a trigger ktery pri kazdem updatu zvedne tuto verzi bez ohledu na hodnotu
kterou do updatu posilas. Kdyz si zaznam stahujes, musis si stahnout i
aktualni hodnotu verze a kdyz ho updatujes, mel by SQL prikaz vypadat
takto: UPDATE zasoby SET .... WHERE id=:id AND verze=:verze
pokud ti RowsAffected vrati 0 zmenenych vet, doslo k tomu ze nejaky
user tesne pred tebou ulozil zmenu a mas chybu kterou muzes
oznamit, nebo spis v tomto pripade na ni reagovat novym nactenim
aktualniho stavu toho zaznamu, snizenim stavu zasob a novym pokusem
o ulozeni. Mozna by se to dalo dat do ulozene procedury a volat
primo ji.
Martin Schayna
Odpovedá: Ludek ZITA
13. 12. 2002 17:48
----- Original Message -----
From: "Karel Rys" <delphi@zas-me.cz>
>
> > Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak
> > je neco seredne spatne s navrhem databaze i aplikace.
>
> S tim bych tak docela nesouhlasil.
>
> Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne. Pri
zapsani radku do prodejniho
> dokladu je nutne snizit fyzickou zasobu. Zde je proste treba pripadny
konflikt nejak osetrit,
> podle meho nazoru nejde predejit moznosti, ze ke konfliktu dojde... Je ale
pravda, ze pokud je
> rychla sit, transakce potrva kratkou dobu a ta pravdepodobnost neni az
*tak velka*
Ahoj.
No tohle je zrovna misto, ktere bych resil nasledovne :
1) Nacteni fyzickeho stavu jen pro informaci prodejce
2) Ted muze prodejce klidne pul hodiny offline vytvaret doklad kafrat se
zakaznikem atd.
3) Prodejce odpali tlacitko uloz.
4) Nactu okamzite mnozstvi na fyz stavu a kontroluji zda se nedostavam do
konfliktu s vydavanym mnozstvim (zda nejde sklad do minusu)
pripadne upozornim, ze je jiz doprodano a jdo zpet na 2)
5) Nastartuji transakci a zapisuji radek po radku doklad, a znovu kontroluji
rozdil oproti stavu ziskanemu v bode 4 v pripade rozdilu posilam hlaseni a
znovu opakuji od bodu 2)
Cele se to da jeste vysperkovat tim, ze nehybu primo fyzickym stavem, ale
jen jakousi blokaci a fyzicky stav se pohne az napriklad po vydani
skladnikem.
Ludek
Odpovedá: Martin Schayna
13. 12. 2002 18:14
----- Original Message -----
From: "Ludek ZITA" <konference@sales.cz>
> From: "Karel Rys" <delphi@zas-me.cz>
> No tohle je zrovna misto, ktere bych resil nasledovne :
> 1) Nacteni fyzickeho stavu jen pro informaci prodejce
> 2) Ted muze prodejce klidne pul hodiny offline vytvaret doklad kafrat se
> zakaznikem atd.
> 3) Prodejce odpali tlacitko uloz.
> 4) Nactu okamzite mnozstvi na fyz stavu a kontroluji zda se nedostavam do
> konfliktu s vydavanym mnozstvim (zda nejde sklad do minusu)
> pripadne upozornim, ze je jiz doprodano a jdo zpet na 2)
> 5) Nastartuji transakci a zapisuji radek po radku doklad, a znovu kontroluji
> rozdil oproti stavu ziskanemu v bode 4 v pripade rozdilu posilam hlaseni a
> znovu opakuji od bodu 2)
Hmm, jestli jsem pochopil spravne zkracujes na nejmensi moznou dobu
mezi nactenim stareho stavu a zapisem zmeny. Ale stejne se ti do te doby
muze vejit nejaka cizi transakce jineho klienta a ty ji svym zapisem
prepises. To bys opravdu musel ten zaznam nacitat ve stejne transakci
ve ho budes ukladat a jeste ho musel nejak pesimisticky zamknout napr.
pomoci falesneho UPDATU nebo SELECT ... FOR UPDATE ne?
Martin Schayna
Odpovedá: Ludek ZITA
13. 12. 2002 20:58
----- Original Message -----
From: "Martin Schayna" <mschayna@aktis.cz>
Hmm, jestli jsem pochopil spravne zkracujes na nejmensi moznou dobu
mezi nactenim stareho stavu a zapisem zmeny. Ale stejne se ti do te doby
muze vejit nejaka cizi transakce jineho klienta a ty ji svym zapisem
prepises. To bys opravdu musel ten zaznam nacitat ve stejne transakci
ve ho budes ukladat a jeste ho musel nejak pesimisticky zamknout napr.
pomoci falesneho UPDATU nebo SELECT ... FOR UPDATE ne?
*********************
Ahoj.
Ano ta posledni transakce uz by nemela byt "optimisticka". Je take co mozno
nejkratsi.
Tady je videt, ze transakcni zpracovani s optimistickym zamykanim nemusi byt
vzdy to nejlepsi. Lepe by bylo pozadavky na zmeny poslat aplikacnimu serveru
a ten by konflikty vyresil seriovym zpracovanim pozadavku. Take lze (ovsem
podle rozsahu dat) zvolit zpusob, kdy se vypocet skladu provadi az ze
skutecne zapsanych vydeju a prijmu od nejakeho pevneho bodu. Treba v noci
provedu prepocet stavu zasob a pres den si k nemu dopocitam z prijmu a
vydaju aktualni stav.
Tech zpusobu a kombinaci je hodne a zadny nikdy nemuze vest ke
stoprocentnimu vysledku. Dalsi "kamen" urazu u ekonomickych evidenci je u
pridelovani cisel dokladu s pozadavkem neprerusitelnost rady a podobne.
Jedine opravdu dokonale reseni je seriovy pristup k takhle citlivym
evidencim a ten se primym pristupem klientu k SQL datum dela hodne spatne
resp. je mozny jedine pomoci nejkeho zamykani, bud primo zaznamu nebo treba
pomoci zamku na spusteni SP ktera pak vzdy ceka na ukonceni akce
predchazejiciho klienta.
Je to sice pracne a ma to take svoje uskali, ale data jsou pro cteni a zapis
nekritickych udaju rychle pristupna.
Ludek
Odpovedá: Lauko Stefan
13. 12. 2002 19:52
----- Original Message -----
From: "Karel Rys" <delphi@zas-me.cz>
Sent: Friday, December 13, 2002 3:44 PM
> Pavel Cisar dne 12 Dec 2002 v 18:15:
>
> > Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak
> > je neco seredne spatne s navrhem databaze i aplikace.
>
> S tim bych tak docela nesouhlasil.
>
> Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne. Pri
zapsani radku do prodejniho
> dokladu je nutne snizit fyzickou zasobu. Zde je proste treba pripadny
konflikt nejak osetrit,
> podle meho nazoru nejde predejit moznosti, ze ke konfliktu dojde... Je ale
pravda, ze pokud je
> rychla sit, transakce potrva kratkou dobu a ta pravdepodobnost neni az
*tak velka*
>
> Karel Rys
Ja si myslim ze zasobu zbozi v takom pripade nie je mozne ukladat v tabulke
a online aktualizovat.
Vznikol by z toho poriadny zmatok. Ja taketo podobne problemy riesim
vypoctom - nemam ziadny stav zasob.
Stav zasob vzdy vypocitam z pohybov.
Napr. do tabulky pohybov dam minimum udajov - stlpcov (aby to nebolo velke)
a jeden zo stlpcov je napr. "krat Smalint", potom prijem=1 vydaj=-1 (toto
je mozne zadat napr. v ciselnikoch druh pohybu).
Stav potom zistim v SP
select sum(mn * krat) From pohyby Where IDpolozky = ID
Je to dost rychle aj pri niekolko stotisic polozkach. A nemusim vobec nic
blokovat. Do pohybov na 90% ide len Insert.
Ale je mozne spekulovat a dopracovat sa k vysledku aj na otazku
"co bolo
skorej vajce alebo sliepka?"
Lauko.
Odpovedá: Pavel Cisar
13. 12. 2002 20:15
Haj hou!
On 13 Dec 2002 at 15:44, Karel Rys wrote:
> Pavel Cisar dne 12 Dec 2002 v 18:15:
>
> > Pokud je *velka* pravdepodobnost kolize operaci update a delete, pak
> > je neco seredne spatne s navrhem databaze i aplikace.
>
> S tim bych tak docela nesouhlasil.
>
> Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne. Pri
> zapsani radku do prodejniho dokladu je nutne snizit fyzickou zasobu.
> Zde je proste treba pripadny konflikt nejak osetrit, podle meho nazoru
> nejde predejit moznosti, ze ke konfliktu dojde... Je ale pravda, ze
> pokud je rychla sit, transakce potrva kratkou dobu a ta
> pravdepodobnost neni az *tak velka*
Vzhledem k tomu, ze nejcastejsi je insert, tak provadet update v ramci
operace vkladani nejakych dat je silenstvi, protoze tim automaticky
vytvaris uzke hrdlo na nejbeznejsi operaci. Uzivatele vkladaji ruzna data
(doklady), ale aktualizuji jeden zaznam (skladovou kartu), takze
pravdepodobnost kolize u nejcasteji provadene operace je razem 80% a
vice. Krasna ukazka spatneho navrhu.
Stav na karte se da vypocitat ze zdrojovych dokladu kdykoliv je potreba,
a SQL servery to umi rychle a spolehlive. Pokud je prvotnich dat mnoho a
trva to prokazatelne prilis dlouho, lze realizovat castecnou optimalizaci
napr. nasledovne:
- Na karte je stav k urcitemu okamziku (napr. posledni pulnoci)
- K tomu se dopocitava prubezny zbytek ze zdrojovych dokladu, nebo z
pomocne tabulky (ma jen par sloupcu = spousta radek na stranku db = vetsi
ucinnost) kam se rovnez vklada mnozstvi a id zbozi.
- Jednou za cas ( napr. o pulnoci) se provede automaticka aktualizace
mnozstvi na skladovych kartach a vymaze se pripadna pomocna tabulka.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Petr Fejfar
13. 12. 2002 20:41
From: "Martin Schayna" <mschayna@aktis.cz>
> Ja chci odstranit dlouhotrvajici transakce,
To jsem pochopil, ale nevim, proc na to pouzivas extra TCP server.
> BTW, to co popisujes tj. metody LOCK a RELEASE
> jsou metody ceho?
To nejsou metody ale operace - je celkem lhostejne, jakou formu
bude mit jejich implementace. Rekneme, ze LOCK by mohl
schematicky vypadat treba nejak takto:
procedure Lock(aDB:TIBDatabase; const aID:ANSIString);
var
XAN: TIBTransaction;
QRY: TIBQuery;
USR: ANSIString;
begin
XAN := TIBTransaction.Create(nil);
try
XAN.Params.Add('isc_tpb_protected');
XAN.Params.Add('isc_tpb_lock_write');
XAN.Params.Add('.....');
QRY := TIBQuery.Create(nil);
try
QRY.Database := aDB;
QRY.Transaction := XAN;
try
XAN.StartTransaction;
QRY.SQL.Add('INSERT INTO TxLOCKS (pkLockID,....) VALUES
(:ID,....)');
QRY.ParamByName('ID').AsString := aID;
QRY.ExecSQL;
XAN.Commit;
except
try
USR:= PickUpUserName(QRY,aID);
except
USR := 'Unknown';
end;
XAN.Rollback;
raise xPublished.CreateFmt('Already locked by "%s"',[USR]);
end;
finally
QRY.Free;
end;
finally
XAN.Free;
end;
end;
***
Samozrejme, ze se nabizi vytvoreni zamku .jako tridy s atributy QRY, XAN
etc...
a metodami Lock() a Release().
HTH, pf
Odpovedá: Viliam Mlich
13. 12. 2002 22:49
> je nutne snizit fyzickou zasobu. Zde je proste
> treba pripadny konflikt nejak osetrit,
To je prave ta zakladna chyba! Ze pri navrhu datoveho modelu niekto
vobec da na kartu pole ZASOBA. Ta sa zasadne neuklada, ale zistuje ako:
SELECT SUM(MNOZSTVO) AS ZASOBA
FROM POHYBY WHERE CISLOKARTY = :karta
Aj pri niekolko tisic pohyboch na karte to pri vhodnom nastaveni indexov
zisti SQL server prekvapivo rychlo.
Az ked by ta rychlost vadila, je mozne zavesit trigger na zmenu v POHYBY
a pre prislusnu kartu robit prepocet do pola ZASOBA. Pochopitelne by
pravo zapisu do toho pola mal len trigger a klienti by hodnotu z karty
iba citali.
A problem formulara, ktory si niekto vysvieti, hodinu opravuje a potom
necha ulozit zmeny? Tu je najrozumnejsie drzat historiu, t.j. odvtedy
dovtedy platil nazov 'matica zinkova' a zapisal ho Skladnik1.
Nasledujucich 0.3 sekundy platil nazov 'matica pozink.' a zapisal ho
Skladnik2. A odvtedy az doteraz pre kartu 024817 plati nazov
'Matica
pozinkovana' ktory urcil Skladnik1.
Keby sme pripustili, ze potom pride Sef a moze povedat, ze vsetko je
inak a ze ten posledny nazov platil odjakziva a nic ine nebolo, tak
potom budeme tazko zistovat, kde sa vzala ta orazitkovana vydajka na 4
kusy zinkovej matice z karty 024817, ked ta karta je pre pozinkovane
matice.
bye
vmlich
Odpovedá: Karel Rys
16. 12. 2002 8:34
Pavel Cisar dne 13 Dec 2002 v 19:57:
> > Tabulka se zasobou zbozi. Prodava se na vice pocitacich soucasne.
> > Pri zapsani radku do prodejniho dokladu je nutne snizit fyzickou
> > zasobu. Zde je proste treba pripadny konflikt nejak osetrit, podle
> > meho nazoru nejde predejit moznosti, ze ke konfliktu dojde... Je ale
> > pravda, ze pokud je rychla sit, transakce potrva kratkou dobu a ta
> > pravdepodobnost neni az *tak velka*
>
> Vzhledem k tomu, ze nejcastejsi je insert, tak provadet update v ramci
> operace vkladani nejakych dat je silenstvi, protoze tim automaticky
> vytvaris uzke hrdlo na nejbeznejsi operaci. Uzivatele vkladaji ruzna
> data (doklady), ale aktualizuji jeden zaznam (skladovou kartu), takze
> pravdepodobnost kolize u nejcasteji provadene operace je razem 80% a
> vice. Krasna ukazka spatneho navrhu.
Ahoj,
to prece neni pravda. Skladovych polozek je zhruba 12.000. Soucasne prodava
max. 10 lidi, kazdy z
nich v danou chvili muze zapisovat nejvyse 1 radek prodejniho dokladu. Ihned po
zapsani radku se v
ramci jedne transakce provede INSERT tohoto radku a UPDATE radku v tabulce
zasoby (popr. take
INSERT, pokud se radek do zasoby nove pridava). Pokud pri .Post radku se
zasobou dojde k chybe -
mezitim to zaktualizoval nekdo jiny, uzivatel bohuzel musi tento radek zapsat
znovu. Cela
transakce je pomerne kratka; podle error logu nastala situace, ze nekdo musel
jeden radek dokladu
napsat znovu kvuli konfliktu pri uprave zasoby, pouze 2x za cely letosni rok.
Zapsanych radku je
zhruba 90.000, takze k 80% pravdepodobnosti se to rozhodne neblizi.
> Stav na karte se da vypocitat ze zdrojovych dokladu kdykoliv je
> potreba, a SQL servery to umi rychle a spolehlive. Pokud je prvotnich
> dat mnoho a trva to prokazatelne prilis dlouho, lze realizovat
> castecnou optimalizaci napr. nasledovne:
>
> - Na karte je stav k urcitemu okamziku (napr. posledni pulnoci)
> - K tomu se dopocitava prubezny zbytek ze zdrojovych dokladu, nebo z
> pomocne tabulky (ma jen par sloupcu = spousta radek na stranku db =
> vetsi ucinnost) kam se rovnez vklada mnozstvi a id zbozi. - Jednou za
> cas ( napr. o pulnoci) se provede automaticka aktualizace mnozstvi na
> skladovych kartach a vymaze se pripadna pomocna tabulka.
Mas pravdu, tohle by teoreticky mohlo fungovat, ovsem pak je zase o poznani
slozitejsi zjisteni
napr. aktualni zasoby urciteho zbozi nebo tisk sestavy s aktualni zasobou vseho
zbozi.
Karel Rys
Odpovedá: Karel Kral
16. 12. 2002 9:22
Hmm, a co kdyz mas mesicne milion pohybu? To asi nebude ono.
Lauko Stefan wrote:
>
> Stav potom zistim v SP
> select sum(mn * krat) From pohyby Where IDpolozky = ID
> Je to dost rychle aj pri niekolko stotisic polozkach. A nemusim vobec nic
> blokovat. Do pohybov na 90% ide len Insert.
>
--
______________________________________________________
Karel Kral, vedouci odd. IT / IT dep. manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral@purus.cz, WWW: http://www.purus.cz
______________________________________________________
Odpovedá: Zbysek Hlinka
16. 12. 2002 9:46
On 16 Dec 2002 at 8:29, Karel Rys wrote:
> > Vzhledem k tomu, ze nejcastejsi je insert, tak provadet update v
> > ramci operace vkladani nejakych dat je silenstvi, protoze tim
> > automaticky vytvaris uzke hrdlo na nejbeznejsi operaci. Uzivatele
> > vkladaji ruzna data (doklady), ale aktualizuji jeden zaznam
> > (skladovou kartu), takze pravdepodobnost kolize u nejcasteji
> > provadene operace je razem 80% a vice. Krasna ukazka spatneho
> > navrhu.
>
> to prece neni pravda. Skladovych polozek je zhruba 12.000. Soucasne
> prodava max. 10 lidi, kazdy z nich v danou chvili muze zapisovat
> nejvyse 1 radek prodejniho dokladu. Ihned po zapsani radku se v ramci
> jedne transakce provede INSERT tohoto radku a UPDATE radku v tabulce
> zasoby (popr. take INSERT, pokud se radek do zasoby nove pridava).
> Pokud pri .Post radku se zasobou dojde k chybe - mezitim to
> zaktualizoval nekdo jiny, uzivatel bohuzel musi tento radek zapsat
> znovu. Cela transakce je pomerne kratka; podle error logu nastala
> situace, ze nekdo musel jeden radek dokladu napsat znovu kvuli
> konfliktu pri uprave zasoby, pouze 2x za cely letosni rok. Zapsanych
> radku je zhruba 90.000, takze k 80% pravdepodobnosti se to rozhodne
> neblizi.
No nevim, ale ke kolizi doslo 2x, takze to neni realnych 80%, ale
100%, rekl bych. Tech 20% a mene je pravdepodobnost, ze ke kolizi
vubec nedojde. To, ze problem skutecne nastal, je pak dokladem o
chybnem navrhu.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Karel Kral
16. 12. 2002 9:38
Tak nevim...
Predstav si, ze v nasi firme je on-line prodej s milionem prodejnich
radku mesicne. A v kazdem okamziku sedi na databazi 10 telefonistek,
ktere pouze berou objednavky a on-line je zapisuji. A take potrebuji v
kazdem okamziku znat presny stav, aby mohly rict mame-nemame. To opravdu
kazda telefonistka pri kazdem radku sve objednavky (asi kazdych 5 sec)
ma spustit dotaz, ktery spocita stav na sklade? I kdyby to byl stav k
pulnoci, bude se muset projit min. tesitky tisic radku. Nevznikne zase
tady sakra uzke hrdlo?
Pavel Cisar wrote:
>
> Stav na karte se da vypocitat ze zdrojovych dokladu kdykoliv je potreba,
> a SQL servery to umi rychle a spolehlive. Pokud je prvotnich dat mnoho a
> trva to prokazatelne prilis dlouho, lze realizovat castecnou optimalizaci
> napr. nasledovne:
>
> - Na karte je stav k urcitemu okamziku (napr. posledni pulnoci)
> - K tomu se dopocitava prubezny zbytek ze zdrojovych dokladu, nebo z
> pomocne tabulky (ma jen par sloupcu = spousta radek na stranku db = vetsi
> ucinnost) kam se rovnez vklada mnozstvi a id zbozi.
> - Jednou za cas ( napr. o pulnoci) se provede automaticka aktualizace
> mnozstvi na skladovych kartach a vymaze se pripadna pomocna tabulka.
>
--
______________________________________________________
Karel Kral, vedouci odd. IT / IT dep. manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral@purus.cz, WWW: http://www.purus.cz
______________________________________________________
Odpovedá: Karel Rys
16. 12. 2002 10:30
Zbysek Hlinka dne 16 Dec 2002 v 8:43:
> > to prece neni pravda. Skladovych polozek je zhruba 12.000. Soucasne
> > prodava max. 10 lidi, kazdy z nich v danou chvili muze zapisovat
> > nejvyse 1 radek prodejniho dokladu. Ihned po zapsani radku se v
> > ramci jedne transakce provede INSERT tohoto radku a UPDATE radku v
> > tabulce zasoby (popr. take INSERT, pokud se radek do zasoby nove
> > pridava). Pokud pri .Post radku se zasobou dojde k chybe - mezitim
> > to zaktualizoval nekdo jiny, uzivatel bohuzel musi tento radek
> > zapsat znovu. Cela transakce je pomerne kratka; podle error logu
> > nastala situace, ze nekdo musel jeden radek dokladu napsat znovu
> > kvuli konfliktu pri uprave zasoby, pouze 2x za cely letosni rok.
> > Zapsanych radku je zhruba 90.000, takze k 80% pravdepodobnosti se to
> > rozhodne neblizi.
>
> No nevim, ale ke kolizi doslo 2x, takze to neni realnych 80%, ale
> 100%, rekl bych. Tech 20% a mene je pravdepodobnost, ze ke kolizi
> vubec nedojde. To, ze problem skutecne nastal, je pak dokladem o
> chybnem navrhu.
Kdyby nas tyhle 2 pripady za rok tak moc trapily, daly by se jiste osetrit lepe
nez chybovym
hlasenim.
Ja mluvil o pravdepodobnosti, ze dojde ke kolizi pri soucasne praci libovolnych
2 uzivatelu - a to
by bylo tedy spise 0.0022 %. Obecne se da predpokladat, ze za dostatecne
dlouhou dobu pri praci se
sdilenymi zdroji ke kolizi proste dojde, ne? Otazka jen je, jak casto k tomuto
jevu dochazi. Co
jsem ja z error logu ovsem nepoznal, je pricina teto kolize. Mohl to opravdu
byt soucasny zapis
stejneho zbozi, ale pravdepodobnejsi je kolize s importem/exportem na ostatni
pobocky, ktery bezi
na pozadi. A k te muze dojit, at uz pouziju jakou chci metodu (ostatne
uzivatele predem odklepnou
hlasku, at chvilku vydrzi, ze bezi export, a zapisuji tak na "vlastni riziko" s
tim, ze vedi o
moznosti, ze budou muset ten jeden radek zapsat znovu).
Karel Rys
Odpovedá: Pavel Cisar
16. 12. 2002 11:48
Haj hou!
On 16 Dec 2002 at 8:46, Karel Kral wrote:
> Predstav si, ze v nasi firme je on-line prodej s milionem prodejnich
> radku mesicne. A v kazdem okamziku sedi na databazi 10 telefonistek,
> ktere pouze berou objednavky a on-line je zapisuji. A take potrebuji v
> kazdem okamziku znat presny stav, aby mohly rict mame-nemame. To opravdu
> kazda telefonistka pri kazdem radku sve objednavky (asi kazdych 5 sec)
> ma spustit dotaz, ktery spocita stav na sklade? I kdyby to byl stav k
> pulnoci, bude se muset projit min. tesitky tisic radku. Nevznikne zase
> tady sakra uzke hrdlo?
Celkovy objem radku nehraje az takovou roli, protoze se dela cileny vyber
za druh zbozi podle indexu -> od kazdeho jich neni tolik a je to rychle
diky indexu a vyuziti cache.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Pavel Cisar
16. 12. 2002 11:55
Haj hou!
On 16 Dec 2002 at 8:29, Karel Rys wrote:
> to prece neni pravda. Skladovych polozek je zhruba 12.000. Soucasne
> prodava max. 10 lidi, kazdy z nich v danou chvili muze zapisovat
> nejvyse 1 radek prodejniho dokladu. Ihned po zapsani radku se v ramci
> jedne transakce provede INSERT tohoto radku a UPDATE radku v tabulce
> zasoby (popr. take INSERT, pokud se radek do zasoby nove pridava).
> Pokud pri .Post radku se zasobou dojde k chybe - mezitim to
> zaktualizoval nekdo jiny, uzivatel bohuzel musi tento radek zapsat
> znovu.
Chces rici, ze kazdy radek je ukladan v samostatne transakci ? To by sice
vyrazne snizilo pravdepodobnost i dopad kolize, ale je to velmi neobvykle
(Jak rusite cely doklad ?). Typicky se uklada cely doklad v ramci jedine
transakce. S poctem radku umerne stoupa pravdepodobnost kolize.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Richard Kejval
16. 12. 2002 11:41
> Tak nevim...
> Predstav si, ze v nasi firme je on-line prodej s milionem prodejnich
> radku mesicne. A v kazdem okamziku sedi na databazi 10 telefonistek,
> ktere pouze berou objednavky a on-line je zapisuji. A take potrebuji v
> kazdem okamziku znat presny stav, aby mohly rict mame-nemame. To opravdu
> kazda telefonistka pri kazdem radku sve objednavky (asi kazdych 5 sec)
> ma spustit dotaz, ktery spocita stav na sklade? I kdyby to byl stav k
> pulnoci, bude se muset projit min. tesitky tisic radku. Nevznikne zase
> tady sakra uzke hrdlo?
Sklad jsem sice nikdy neresil, ale co treba takhle. Mezivysledek sice nekam
ukladat, ale plnit ho pouze pomoci triggeru o potrebny prirustek. Pokud
transakce trva kratkou dobu, muzu si dovolit ji nastavit tak, aby cekala az
na ni dojde rada.
Vyhody:
1. Soucet mam okamzite k dispozici i pokud pracuji s milionovymi tabulkami.
2. V pripade chyby mohu tyto vysledky kdykoliv prepocitat, ikdyz by k tomu
nemelo nikdy dojit.
Nevyhoda:
V pripade konfliktu by transakce dele trvala, ale to by snad nemuselo
vadit.
S pozdravem
ing. Richard Kejval
IC Software s.r.o
Mobil: +420602477679
Odpovedá: Lstiburek Pavel
16. 12. 2002 12:32
Nevim co chces presne pri vydeji delat (ocenovani vydaje...), ale myslim si,
ze to chce nedelat pokud mozno nic.
Aktualizaci skladove karty si zavesit to pod trigger:
- vlozeni odecet stavu na karte ( - vysledek < 0 chyba doslo !!)
- vymaz pricist na kartu
- oprava vymaz+vlozeni.
Transakce budou kratke, jednoduche
a mohou mit pozadovanou uroven isolace !
Vsechny ostani kejkle se zasobami si nechat na uzaverku dne.
Jinak souhlasim, s P.Cisarem, pokud je rozlozeni nakupovanych polozek
rovnomerne a jsou dobre definovany indexi, melo by zatize i pri
prubeznem sumovani byt male (respektive prijatelne).
Pavel
> From: Pavel Cisar [mailto:pcisar@users.sourceforge.net]
> > Predstav si, ze v nasi firme je on-line prodej s milionem prodejnich
> > radku mesicne. A v kazdem okamziku sedi na databazi 10 telefonistek,
> > ktere pouze berou objednavky a on-line je zapisuji. A take
> potrebuji v
> > kazdem okamziku znat presny stav, aby mohly rict
> mame-nemame. To opravdu
> > kazda telefonistka pri kazdem radku sve objednavky (asi
> kazdych 5 sec)
> > ma spustit dotaz, ktery spocita stav na sklade? I kdyby to
> byl stav k
> > pulnoci, bude se muset projit min. tesitky tisic radku.
> Nevznikne zase
> > tady sakra uzke hrdlo?
>
> Celkovy objem radku nehraje az takovou roli, protoze se dela
> cileny vyber
> za druh zbozi podle indexu -> od kazdeho jich neni tolik a je
> to rychle
> diky indexu a vyuziti cache.
Odpovedá: Karel Rys
16. 12. 2002 17:16
Pavel Cisar dne 16 Dec 2002 v 10:59:
>
> > to prece neni pravda. Skladovych polozek je zhruba 12.000. Soucasne
> > prodava max. 10 lidi, kazdy z nich v danou chvili muze zapisovat
> > nejvyse 1 radek prodejniho dokladu. Ihned po zapsani radku se v
> > ramci jedne transakce provede INSERT tohoto radku a UPDATE radku v
> > tabulce zasoby (popr. take INSERT, pokud se radek do zasoby nove
> > pridava). Pokud pri .Post radku se zasobou dojde k chybe - mezitim
> > to zaktualizoval nekdo jiny, uzivatel bohuzel musi tento radek
> > zapsat znovu.
>
> Chces rici, ze kazdy radek je ukladan v samostatne transakci ? To by
> sice vyrazne snizilo pravdepodobnost i dopad kolize, ale je to velmi
> neobvykle (Jak rusite cely doklad ?). Typicky se uklada cely doklad v
> ramci jedine transakce. S poctem radku umerne stoupa pravdepodobnost
> kolize.
Po zapisu kazdeho radku je ihned CommitRetaining. Pri mazani dokladu to trva
chvili dele, to je
pravda, Commitne se to najednou, az po smazani vsech radku a zahlavi; tady je
ta pravdepodobnost
kolize o neco vyssi, na druhou stranu se zase stava jen velmi zridka, ze se
maze cely doklad.
Nechali jsme to po zapisu kazdeho radku, protoze nekdy opravdu potrebujeme
aktualni zasobu a tech
nekolik dokladu, ktere mohou byt rozepsane, by ji mohlo zrovna znatelne
ovlivnit.
Karel Rys
Odpovedá: Martin Schayna
17. 12. 2002 14:04
----- Original Message -----
From: "Petr Fejfar" <development@callnet.cz>
> From: "Martin Schayna" <mschayna@aktis.cz>
>
> > BTW, to co popisujes tj. metody LOCK a RELEASE
> > jsou metody ceho?
>
> To nejsou metody ale operace - je celkem lhostejne, jakou formu
> bude mit jejich implementace. Rekneme, ze LOCK by mohl
> schematicky vypadat treba nejak takto:
> ...
>
QRY.SQL.Add('INSERT INTO TxLOCKS (pkLockID,....) VALUES
> (:ID,....)');
>
A to se nebojis ze ti z nejakeho duvodu klient v prubehu prace
odpadne a v te tabulce zustanou zaznamy o jeho zamcich???
Pak budes muset slozite resit jejich uvolnovani pomoci nejaky
nastroju aby mohli uzivatele pracovat...
Ten TCP server by mel tu vyhodu ze po rozpojeni (napr. pri
nasilnem odpadnuti klienta) by se jeho zamky samy uvolnily
protoze by byly realizovane pouze v pameti.
Martin Schayna
Odpovedá: Petr Fejfar
17. 12. 2002 22:04
From: "Martin Schayna" <mschayna@aktis.cz>
> A to se nebojis ze ti z nejakeho duvodu klient v prubehu prace
> odpadne a v te tabulce zustanou zaznamy o jeho zamcich???
Nebojim, protoze jsem dosud nepotreboval zamykat SQL server 
> Pak budes muset slozite resit jejich uvolnovani pomoci nejaky
> nastroju aby mohli uzivatele pracovat...
Ten zamek implementovany pres DB tabulku by mel samozrejme
time stamp a expiroval by - zamek by zustal zamceny+expirovany
do doby, nez ho bude chtit zamknout jiny klient popr. se expirovane
zamky daji odstranit v ramci house keepingu.
A pokud by to bylo nutne, tak by zrejme nebyl problem zajistit
pravidelny update zaznamu a tim simulovat funkci watch-dogu
(zkracenim doby expirace).
Asi bych to implementoval pomoci SP.
> Ten TCP server by mel tu vyhodu ze po rozpojeni
Me spis napadaji dve nevyhody:
1. musis mit vhodne nastaveny firewally pro ten TCP server
2. musis mit zajisteno, aby ten TCP server opravdu bezel
Bye, pf